1. Field of Invention
The present invention relates to input/output (IO) stream adaptive write caching policy adjustment in a storage virtualization subsystem.
2. Description of Related Art
Storage virtualization is a technology that has been used to virtualize physical storage by combining sections of physical storage devices (PSDs) into logical storage entities, herein referred to as logical media units that are made accessible to a host system. This technology has been used primarily in redundant arrays of independent disks (RAID) storage virtualization, which combines smaller physical storage devices into larger, fault tolerant, higher performance logical media units via RAID technology.
A logical media unit, abbreviated LMU, is a storage entity whose individual storage elements (e.g., storage blocks) are uniquely addressable by a logical storage address. One common example of a LMU is the presentation of the physical storage of a hard disk drive (HDD) to a host over the host IO-device interconnect. In this case, while on the physical level, the HDD is divided up into cylinders, heads and sectors, what is presented to the host is a contiguous set of storage blocks (sectors) addressed by a single logical block address. Another example is the presentation of a storage tape to a host over the host IO-device interconnect.
A storage virtualization controller, abbreviated SVC, is a device the primary purpose of which is to map combinations of sections of physical storage media to LMUs visible to a host system. IO requests received from the host system are parsed and interpreted and associated operations and data are translated into physical storage device IO requests. This process may be indirect with operations cached, delayed (e.g., write-back), anticipated (read-ahead), grouped, etc. to improve performance and other operational characteristics so that a host IO request may not necessarily result directly in physical storage device IO requests in a one-to-one fashion.
An external (sometimes referred to as “stand-alone”) storage virtualization controller is a storage virtualization controller that connects to the host system via an IO interface and that is capable of supporting connection to devices that reside external to the host system and, otherwise, operates independently of the host.
One example of an external storage virtualization controller is an external, or stand-alone, direct-access RAID controller. A RAID controller combines sections on one or multiple physical storage devices (PSDs), the combination of which is determined by the nature of a particular RAID level, to form LMUs that are contiguously addressable by a host system to which the LMU is made available. A single RAID controller will typically support multiple RAID levels so that different LMUs may consist of sections of PSDs combined in different ways by virtue of the different RAID levels that characterize the different units.
Another example of an external storage virtualization controller is a JBOD emulation controller. A JBOD, short for “just a bunch of drives”, is a set of PSDs that connect directly to a host system via one or more a multiple-device IO device interconnect channels. PSDs that implement point-to-point IO device interconnects to connect to the host system (e.g., parallel ATA HDDs, serial ATA HDDs, etc.) cannot be directly combined to form a “JBOD” system as defined above for they do not allow the connection of multiple devices directly to the IO device channel.
Another example of an external storage virtualization controller is a controller for an external tape backup subsystem.
A storage virtualization subsystem (abbreviated SV subsystem, or SVS) consists of one or more above-mentioned SVCs or external SVCs, and at least one PSD connected thereto to provide storage therefor.
Storage virtualization commonly incorporates data caching to enhance overall performance and data throughput. This data caching typically consists of caching read data and caching write data. Caching write data can further be divided into write-back caching and write-through caching. In write-back caching, the response to the host that a write operation has completed is sent out as soon as the associated data is received by the SVS and registered into the cache. It is not committed to physical media until some later time. In write-through caching, the response to the host that a write operation has completed is delayed until after the associated data is completely committed to physical media.
Write-back caching, in general, has the benefit of improving performance. By responding to the host as soon as data arrives rather than waiting until it is committed to physical media, typically more host write IOs per unit time can be processed. Furthermore, by accumulating a large amount of data in the cache before actually committing it to physical media, optimization can be performed during the commit process. Such optimizations include reducing the number of write operations to the PSDs by grouping large quantities of data into single write operations and ordering the data thereby reducing PSD mechanical latencies.
Write-through caching has the benefit of improved data security. A sudden loss of power or a failing SVC, for instance, will not result in the loss of data. Under certain circumstances, such as when the write IO stream is sequential in nature and the SVCs are configured into redundant SVS, write-through caching may actually offer better performance. In such a SVS, to avoid data loss in the event of a failing SVC, write-back caching may be combined with inter-controller cached write data synchronization so that there is a backup of all uncommitted write data in the alternate controller in the redundant pair. The process of backing up write data to the alternate controller in real time as it comes in from the host may result in significant performance degradation. In this case, especially if the write IO stream is sequential in nature, write-through caching may actually yield better performance because it is not necessary to backup the data to the alternate controller to avoid data loss in the event of an SVC failure.
In an effort to provide the user with the ability to tune the write caching policy to a setting that he feels is most appropriate for the particular configuration and IO stream characteristics, a typical SVS will support the manual adjustment of the write caching policy. In many systems, this policy is dynamically adjustable, meaning that it takes effect immediately without the need to take associated LMU or perhaps even the entire system off line then bring it on line again. Furthermore, each LMU or even each logical unit that is presented to the host over the host-side IO device interconnect may have its own independently configurable write caching policy. Some SVSs may even support adjustment of the write caching policy on per-IO basis by information conveyed in the IO command information itself.